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One  of  the  goals  continuously  before  ut-  in  computer 
programr.ii  tnj  is  to  seek  out  ways  to  improve,  by  shortening, 
the  amount  of  time  taken  to  solve  problems  on  digital  com¬ 
puters.  One  way  to  achieve  this  goal  is  through  more 
efficient  use  of  the  computing  facilities  which  we  have 
today.  Monitor  systems  made  a  great  stride  toward  this 
goal  by  automating  the  sequencing  of  jobs  through  the  com¬ 
puting  machine,  making  available  on  call  a  number  of  helpful 
programs  for  compiling,  assembling,  converting,  and  editing. 
For  a  number  of  years  a  great  white  hope  has  been  the  multi¬ 
plexing  of  programs  within  a  single  computing  machine.  It 
is  hoped  that,  through  this  technique,  idle  tim.es  of  one 
program  may  be  interleaved  with  computing  times  cf  a  second 
or  third  program  with  the  combination  making  more  efficient 
use  of  the  machine  than  any  one  of  them  could  have  made  by 
itself . 


Any  views  expressed  in  this  Paper  are  those  of  the 
author.  They  should  not  be  interpreted  as  reflecting  the 
views  of  The  RAND  Corporation  or  the  official  opinion  or 
policy  of  any  of  its  governmental  or  private  research 
sponsors.  Papers  are  reproduced  by  The  RAND  Corporation 
as  a  courtesy  to  members  of  its  staff. 

Tins  Pap, or  was  presented  at  the  Twenty-Second  Annual 
Meeting  of  SHARI:,  held  in  San  Francisco,  2-G  March  1964. 


In  multiplex  program  situations,  important  questions 
arise  regarding  storage  allocation,  algorithms  for  choosing 
the  jobs  to  be  run,  proper  timing  of  swapping  of  programs 
in  and  out  of  main  memory,  and  algorithms  for  switching 
between  programs  which  are  already  in  memory.  In  order  to 
answer  these  questions  and  to  design  efficient  algorithms, 
a  number  of  questions  about  the  characteristics  of  the 
programs  being  run  need  to  be  answered.  Algorithms  which 
operate  effectively  in  one  mix  of  program  characteristics 
will  operate  inefficiently  in  other  mixes.  Some  ot  the 
central  questions  involved  are: 

1)  The  distribution  of  program  sizes. 

2)  The  distribution  of  running  times  of  programs. 

3)  The  correlation,  if  any,  between  1  and  2. 

4)  The  characteristics  of  the  use  of  storage  by 
programs . 

5)  Identification  of  idle  intervals  within  a 
pruyium,  and  finding  their  time  distribution. 

In  category  5,  two  areas  seem  apparent.  The  first  is 
stop  time  between  jobs  for  tape  mounting,  finding  the  next 
job,  dumping  the  program,  etc.;  the  second,  those  intervals 
during  which  a  program  waits  for  I/O  actions  to  complete. 

Determining  the  answers  to  these  questions  in  current 
operations  will  help  us  know  whether  program  multiplexing 
is  indeed  a  fruitful  area  for  efficiency  gains,  and,  if 
it  is,  help  us  to  find  out  what  kinds  of  gains  we  can  ex¬ 
pect.  We  should  not,  of  course,  neglect  the  fact  that  the 
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jub  characteristics  which  we  measure  today  are  in  some 
degree  dependent  on  the  current  method  of  operation.  Pro¬ 
grammers,  quite  correctly,  adapt  their  methods  of  operation 
to  the  system  in  which  they  work;  any  change  in  the  system 
can  1 e  expected  to  change  their  habits  somewhat.  It  is 
entirely  possible,  of  course,  that  a  system  design  for 
multiplex  pi egram  operation  will  find  greater  utility  and 
greater  solution  efficiency  than  current  systems  because 
of  the  easing  of  the  difficulties  of  storage  allocation  and 
secondary  storage  utilization. 

In  order  to  examine  some  of  these  questions  in  detail, 
and  to  find  the  characteristics  of  programs  using  the  com¬ 
puter  at  RAND,  a  number  of  statistics  have  been  gathered 
on  actual  program  runs.  Preliminary  results  of  these 
studies  are  given  below. 

Storage  Examination  Program 

The  FORTRAN  EXIT  program,  entered  at  the  end  of  nearly 
every  FORTRAN  job,  has  been  modified  to  include  a  routine 
which  examines  storage  following  the  execution  of  each  job. 
Three  categories  of  jobs  are  not  reflected  in  the  statistics 
gathered  by  this  program: 

1)  Jobs  which  compile  only. 

2)  Jobs  so  large  that  they  cannot  afford  storage 
for  this  program. 
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3)  Jobs  which  arc  dumped  from  the  machine  before 
reaching  the  hXIT  routine.* 

The  storage  scan  routine  breaks  core  into  three  areas: 
the  program  area,  below  the  proqram  break;  the  common  area, 
above  the  common  break;  and  unused  core,  that  port,  ion  bc- 
the  pronram  break  ard  the  comm  cr.  break.  w ;  r  r .  ?  *■ 
of  these  areas,  five  types  of  cells  are  recorded : 

1)  Those  which  are  classed  as  decrement  integers. 

If  prefix  tag  and  address  of  the  word  are  0, 
then  it  is  assumed  to  be  a  decrement  integer. 

2)  Zeros,  both  plus  and  minus. 

3)  Instructions  which  have  nine  b  ts  equal  to  one 
( A XT ,  TSX,  LXD ,  SXD,  etc.). 

4)  Floating-point  numbers--tbose  which  have  the  nine 
bit  equal  to  one,  except  for  those  falling  in 
category  3. 

5)  All  other  cells  which  are  presumably  instructions. 

The  program  punches  an  accounting  card  containing 

these  data,  and  this  accounting  card  is  later  combined  with 
the  ordinary  accounting  cards  produced  for'  the  run. 

Specific  additional  data  gained  by  combining  with  the 
regular  accounting  cards  are  log  on  time,  execution  time, 
and  number  of  output  lines  produced  by  the  program. 

Finally,  the  results  of  these  cards  for  each  job  are 
summarized  by  a  program  which  produces  histograms  of  the 
data  in  various  categories. 


*The  limitation  of  this  last  category  has  been  elimi¬ 
nated  as  of  1  February  1964  by  including  the  storage  scan 
routine  in  the  dump  routine. 
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Freliminary  Hcsults 

Data  has  been  gathered  with  this  storage  cxan^„ai,ion 
program  bim-»  2j  L<occmbcr  1963,  and  histograms  have  been 
run  on  those  programs  i  ur.  between  30  December  196  3  and 
?’  ?aruary  A Luul  190  jobs  were  run  each  day,  t  o- 

thirus  of  them  in  prime  shift. 

The  gross  breakdowns  of  all  jobs  are  shown  in  Fig.  1. 

1  he  histograms  described  below  are  taken  from  statistics 
cards  produced  by  the  60  percent  of  programs  marked  in 
Fig.  1  "FORTRAN  Compile  and  Execute. "  As  can  be  seen, 
these  jobs  represent  48  percent  of  the  running  time.  The 
jobs  were  run  on  19  different  days  during  the  period. 

Figure  2  is  the  distribution  of  the  number  of  0's 
found  in  the  region  of  core  between  the  program  break  and 
common;  thus,  it  is  the  best  measure  we  know  of  the  number 
of  cells  not  used  by  the  program.  The  bucket,  or  interval 
size  is  given  under  the  heading  BKT,  with  the  actual  count 
of  jobs  and  the  percentage  of  jobs  falling  in  each  bucket 
being  given  in  the  first  two  columns.  Thus,  the  figure 
shows  that  64,  or  3.7  percent  of  jobs,  did  not  use  between 
0  and  10CC  cells  of  core.  In  this  particular  bucket, 
representing  very  large  jobs,  the  true  figure  would  be 
larger  by  perhaps  as  much  as  10  percent  since  a  substantial 
fraction  of  jobs  are  not  reflected  because  they  were  too 
large  to  use  this  special  exit  program. 

Since  the  normal  complement  of  FORTRAN  library  routines 
occupies  approximately  2900  to  300U  cells  of  memory,  it  is 
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not  surprising  that  few  jobs  leave  more  than  30,000  cells 
unused.  It  is  interesting,  however,  that  36  percent  of 
all  programs  would  have  run  successfully  in  an  8K  machine. 

Two  programs,  ROCKET  and  SIMSCRIPT,  seem  to  account 
for  the  bulge  in  storage  use  in  the  12-15K  buckets.  We 
should  not  find  it  surprising  that  our  machine  utilization 
characteristics  are  affected  by  popular  programs. 

Interestingly,  only  about  8  percent  of  programs  would 
not  tit  in  core  with  some  other  program  commonly  available. 

Figure  3  presents  the  number  of  0's  found  anywhere  in 
memory-program  area,  unused  storage,  and  common.  Inter¬ 
esting  is  the  fact  that  90  percent  of  programs  leave  half 
of  memory  or  more  zero  following  their  execution;  30  per¬ 
cent  of  programs  leave  90  percent  of  memory  empty.  Ex¬ 
amination  of  Fig.  3--and  Fig.  4  (which  shows  that  the 
number  of  floating-point  cells  found  in  memory  is  surpris¬ 
ingly  small--70  percent  of  programs  with  less  than  2000 
floating-point  numbers ) --makes  immediately  apparent  that 
many  programs  contain  sparse  matrices  or  allocated  but  un¬ 
used  tables.  Clearly,  in  the  case  of  sparse  matrices, 
storage  allocation  techniques  of  the  list  variety  such  as 
I  PL- V  possesses  would  be  of  great  value;  and,  in  the 
second  case,  a  dynamic  storage  allocation  scheme  providing 
storage  only  when  requested  would  save  large  amounts  of 
storage  for  use  by  other  programs. 

Figure  5  shows  actual  program  sizes  as  determined  by 
the  number  of  instructions  in  the  program  and  unused  region. 
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With  the  exception  of  the  popular  SIMSCRIPT  and  ROCKET, 
which  appear  in  the  16,000  instruction  bucket,  most  pro¬ 
grams  are  very  small--50  percent  being  less  than  4000  in¬ 
structions  long.  This  fact,  coupled  with  the  total  alloca¬ 
tion  in  Fig.  2,  forces  one  to  conclude  that  large  amounts 
of  storage  are  assigned  to  tables. 

Figure  6  presents  the  data  of  Fig.  5  (weighted  by 
straight  multiplication)  by  the  execution  time  of  the  pro¬ 
gram  involved.  Since  very  little  change  in  the  distribution 
is  noted,  we  conclude  that  it  is  not  possible  to  tell  from 
the  number  of  instructions  in  a  program  how  long  it  will 
execute.  I'm  sure  no  one  will  be  surprised  by  this  fact. 

Figure  7,  however,  plots  the  number  of  unused  0's 
weighted  by  execution  time.  This  is  the  same  data  as  in 
Fig.  6  and  show';  a  very  pronounced  shift  toward  the  larger 
programs  near  the  top  of  the  chart.  The  peak  of  Fig.  6 
in  the  small  program  region  is  completely  missing  from 
Fig.  7.  Thus,  we  note  the  strong  correlation  (as  shown 
again  in  a  different  way  below)  between  the  size  of  the 
programs  and  their  execution  time.  It  seems  to  be  a  strong 
characteristic  of  programs  that  if  the  space  requested  is 
small,  they  will  run  a  short  time.  If  it  ±s  large,  they 
will  run  a  long  time. 

In  the  5K  and  8K  buckets  may  be  seen  the  pronounced 
effect  of  popular  programs.  This  time,  not  particularly 
big  ones  but  long  running. 
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Figure  8  again  demonstrates  this  shift  b>  plotting 
the  total  number  of  0's  weighted  by  execution  time.  It, 
too,  reinforces  the  thought  that  big  programs  run  a  long 
time  and  little  programs  run  a  short  time.  And  remember, 
these  are  not  instructions  in  the  program  but  total  alloca¬ 
tion  of  storage.  Thus,  while  we  cannot  tell  how  long  a 
program  might  run  by  asking  how  many  instructions  the 
program  contained,  we  can  tell  by  asking  how  many  instruc¬ 
tions  plus  how  many  cells  of  tables  does  it  contain. 

Figure  9  plots  the  number  of  jobs  arriving  at  the 
7090  in  each  hour  of  the  day.  here  the  bucket  column 
represents  an  hour.  Noteworthy  are  the  first  and  second 
shift  lunch-hour  dips  at  12:00  and  20:00  hours.  Also 
apparent  is  the  slow  rise  from  early  morning  to  full  pro¬ 
duction  at  10:00,  and  from  lunch  time  until  full  production 
again  at  2:00.  It  seems  a  full  stomach  is  a  bad  thing  for 
programmers.  Perhaps  we  should  hire  only  hungry  programmers. 

Production  of  output  for  printing  is  a  crucial  one  in 
most  installations,  being  one  of  the  primary  bottlenecks 
hindering  fast  turnaround  time.  Figure  10  plots  the  number 
of  jobs  occurring  in  each  category  of  output  volume.  From 
the  figure,  it  can  be  seen  that  more  than  50  percent  of 
jobs  can  be  printed  using  a  single  600-line-a-minute  printer 
in  a  time  equivalent  to  the  running  time  of  the  job.  Per¬ 
haps  this  is  an  indication  that  we  should  return  to  on-line 
printing.  We  are  certainly  okay  if  we  have  sufficient 
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storage  available  with  which  to  buffer  the  output  so  that 
bursts  of  printed  output  from  the  program  can  be  smoothed 
for  presentation  to  the  printer. 

Most  installations  have  limits  on  the  number  of  lines 
which  may  be  produced  during  the  critical  prime  shift 
hours;  thus,  those  jobs  which  appear  on  this  curve  near  the 
tail  end--the  high,  output  jobs--can  be  expected  to  occur 
during  the  non-critical  third  shift. 

Figure  11  weights  7090  on-time  by  the  number  of  exe¬ 
cution  lines  produced.  Thus,  it  is  a  map  of  the  printer 
load  during  the  day.  Compare  this  figure  with  Fig.  9  and 
note  the  attempt  of  the  noon-time  operator  to  run  the  jobs 
which  produce  more  output,  possibly  the  longer  jobs,  during 
his  rather  hectic  session  at  the  machine. 

Running  Times 

Figure  12  presents  a  number  of  different  distribu¬ 
tions  of  running  times  of  jobs  taken  from  various  studies. 
Although  there  is  a  large  variation  in  the  number  of  jobs 
run  in  any  particular  time  category,  it  is  clear  that  the 
great  bulk  of  jobs  run  for  only  a  short  amount  ot  time. 

The  limitations  usually  imposed  at  computing  installations 
make  this  no  surprise.  Still,  it  is  a  bit  surprising  to 
find  60  percent  or  more  programs  executed  in  less  than 
two  minutes . 

Figure  13's  scatter  diagram  presents  a  correlation  of 
the  execution-time  data  together  with  the  total  program-size 
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data.  As  was  seen  in  the  histograms,  there  is  a  substantial 
correlation  between  job  size  and  running  time.  Note  par¬ 
ticularly  the  largo  group  of  jobs  in  the  under-one-minute 
running  time  and  less  than  4000-in-words  of  storage  category. 
Again,  since  many  of  the  jobs  on  the  opposite  end  of  the 
spectrum--the  large  end--are  run  late  at  night,  wo  find 
small,  short  jobs  a  pronounced  characteristic  of  prime 
shift  jobs. 

Unused  Time 

In  our  supposedly  advanced  monitor  controlled  job  shops, 
we  find  substantia)  portions  cf  unused  time  during  even  the 
busiest  hours  of  the  day.  Figure  14  is  an  example  of  this 
charaeterisi. ,  c.  The  center  cu.ve  plots  the  average  for  6  days 
of  unused  time  during  each  hour.  Note  that  we  are  never 
able  to  utilize  more  than  50  minutes  out  of  each  hour.  Tape 
mounting,  finding  jobs,  and  other  delays  attributable  to 
semi -manual  operation  are  reflected  hero.  It  is  probably 
unreasonable  to  expect  that  any  non-automatic  system  would 
be  able  to  do  better. 

Figure  14  also  plots  the  number  of  jobs  logged  on  each 
hour  and  the  average  time  occupied  by  each  job  during  that 
hour.  Interestingly,  between  }C:00  in  the  morning  and 
8:00  in  the  evening  the  average  job  time  does  not  vary 
substantially  from  the  overall  average  time,  although  late 
at  night  large  jobs  were  indeed  run. 
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It  should  be  pointed  out  that  the  wait  times  reflected 
here  are  the  non-charge  times--and  thus  do  not  reflect 
waiting  time  within  the  program  for  tape  I/O  transmission, 
rewinds,  backspaces,  and  waits  for  the  operator  to  dump  the 
job,  dial  in  tapes,  or  complete  other  manual  operations. 

Figure  15's  scatter-diagram  plots  for  each  hour  one 
point  on  coordinates  of  number  of  jobs  legged  in,  and  idle 
time  for  the  hour.  This  diagram  shows  no  correlation  be¬ 
tween  idle  time  and  nun ber  or  jobs,  indicating  that  the 
job-shop  monitor  is  working  fine  but  that  certain  manual 
delays  are  unavoidable  and  are  independent  of  the  number  of 
jobs  being  processed. 

Summary 

I  believe  that  the  above  statistics  demonstrate  that 
substantial  gains  are  achievable  through  a  multiplexed 
program  mode  of  operation.  Substantial  numbers  of  programs 
exist  in  the  small-time  and  smal 1 -program  size  categories 
to  insure  that  programs  can  be  easily  found  which  will  fit 
available  time-space  slots.  Further,  because  of  these 
factors,  rather  simple  allocation  algorithms  will  be  suf¬ 
ficient.  We  need  not  look  far  ahead  in  the  input  stream 
to  find  a  suitable  job  to  fit  the  dimension  available  in 
either  time  or  space. 

We  have  also  shown  that  there  are  substantial  gains 
to  be  achieved  in  storage  allocation  areas--both  in  list 
processing  styles  of  storage  allocation  in  which  both  the 
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location  and  its  contents  are  important  data  in  the  stor¬ 
age  reference,  and  in  the  dynamic  storage  requests  in 
which  tables  of  nominal  size  are  expended  to  fill  the  needs 
of  the  program  as  it  executes. 

It  would  not  be  overstating  the  case  to  predict  that 
an  efficiency  or  through-put  gain  of  100  percent  is  achiev¬ 
able  through  implementation  of  these  techniques. 


